Administering SQL Server 2008 with PowerShell : Overview of PowerShell

Windows PowerShell was first released to the public in November 2006 as version 1.0. It was released as a separate install for Windows XP and Windows 2003, and shortly after, an install for Windows Vista was made available. Since its release, Windows PowerShell has been downloaded over two million times.

When Windows Server 2008 was released, PowerShell was provided with the operating system. To have access to PowerShell, you simply had to add the Windows PowerShell feature through the new Server Manager.

In 2008, Microsoft announced that PowerShell is now part of its Common Engineering Criteria for 2009 and beyond. This announcement basically means that all of Microsoft’s server products should have some level of PowerShell support. Microsoft Exchange 2007 was the earliest server-class product to come out with full PowerShell support. In fact, all of Exchange’s administrative tasks are based on PowerShell. The PowerShell functionality in Exchange is actually named Exchange Management Shell.

Start Using PowerShell Now

PowerShell supports all the regular DOS commands and can run scripts written in any other language (the script engine specific to that scripting language still needs to be used). If any kind of scripting is currently being done, there is no reason why users can’t start using PowerShell now, even if they are not using its vast functionality.

Common Terminology

Here are some of the common terms used when working with PowerShell:

• Cmdlet— This is the name given to the built-in commands in PowerShell. Cmdlets are the most basic component within PowerShell and are used when doing anything in PowerShell. They are always of the form “verb-noun.” Cmdlets also have arguments called parameters, and values can be passed to these parameters.

• Script— With automation comes the requirement for scripts. Using scripts is as simple as putting a single cmdlet in a file and then executing the file. In PowerShell, scripts have the extension .ps1 and can be executed or invoked by simply calling it as ./my_script.ps1.

• Pipeline— This PowerShell functionality allows a series of cmdlets to be combined together using the pipe character (|). The output from one cmdlet is then piped to the following cmdlet for further processing.

• Provider— Using this PowerShell functionality, a data store is presented to the user in a format similar to a file system. Some of the “core” cmdlets are typically used to do various tasks such as creating items like files and/or folders.

• Snap-in— PowerShell functionality can be extended with the use of snap-ins. They are basically DLL files written in a .NET programming language such as C# or VB.NET. DBAs can load these snap-ins in their PowerShell session to add additional functionality such as additional cmdlets and/or providers.

• Tab completion— This PowerShell functionality allows the user to press the Tab key to autocomplete supported commands and parameters.

• Aliases— Theseare shorter names that can be used for cmdlets. For example, some typical UNIX and DOS commands have had aliases for them created in PowerShell. These aliases map to the actual PowerShell cmdlet.

Object-Based Functionality

As mentioned earlier, PowerShell is built on the .NET Framework. This implies that everything within PowerShell is object based. This is a familiar concept for anyone who is already familiar with the .NET Framework or .NET programming languages such as C# or VB.NET.

This object-based functionality is an important concept to remember if you want to dive deeper into PowerShell. PowerShell provides many features, and it can also use additional features provided by other .NET assemblies.

SQL Server Management Objects

SQL Server Management Objects (SMO) are a very useful tool to advanced users and developers when dealing with the automation of SQL Server 2005 and 2008. A lot of the features within SQL Server (core engine, agent, mail, and so on) are packaged into easy-to-access .NET libraries that can be accessed from PowerShell.

Most of the functionality provided by the new PowerShell support in SQL 2008 is based on SMO.

As for SQL Server 2005, PowerShell can still be used to administer this version via SMO. The only difference is that the relevant assemblies must be loaded manually.

WMI

Windows Management Instrumentation (WMI) is a Windows service that provides remote control and management. PowerShell provides some built-in support for retrieving information via WMI.

Although the main goal of WMI may be to provide remote access, it can also be used locally and can provide a wealth of information about a system. For example, WMI can be used to easily query disk space and installed patches.

Installing PowerShell

As of Windows Server 2008, adding the PowerShell feature is easy using the new Server Manager application. With previous versions of Windows, PowerShell was a separate install, which required downloading and installing an external package.

To install PowerShell on Server 2008, start Server Manager, go to the Features node, then click Add Features, and simply check the box for Windows PowerShell, as shown in Figure 1.

Figure 1. Selecting the Windows PowerShell feature.

PowerShell Console

You can accessing PowerShell directly from the Start menu, by opening All Programs, and choosing Windows PowerShell 1.0, then finally Windows PowerShell (alternatively, on some systems, such as Windows 7, you can find the Windows PowerShell folder under the Accessories folder in the Start menu). The Windows PowerShell console opens, as shown in Figure 2.

Figure 2. Opening the PowerShell console.

Scriptable and Interactive

PowerShell can be used as a scripting language, by creating reusable scripts that can automate various tasks, and it can also be used interactively, by opening up a console window and entering commands line by line.

In interactive mode, PowerShell is intelligent enough to know when a command is not complete and actually displays >> on a new line when it believes a complete command has not been entered.

Default Security

After PowerShell has been installed, it is very secure out of the box. Here are two of the default security features:

• PowerShell cannot run any scripts. If you attempt to double-click on any .ps1 script, it simply opens the contents in Notepad.

• PowerShell cannot be accessed remotely.

Execution Policy

By default, PowerShell can only be used interactively from the console. This is part of the default security. To be able to actually run scripts, you must set the execution policy. The easiest way to set this policy is to use the Set-ExecutionPolicy cmdlet, as follows:

PS>Set-ExecutionPolicy RemoteSigned

Basically, when you use the value RemoteSigned, PowerShell is set to be able to run scripts that have been created locally, but if a script is downloaded from the Internet, for example, it must be signed.

Profiles

As users become more and more familiar with PowerShell, they typically develop customizations that they may want to save for the next time PowerShell is opened. PowerShell has several profiles that can be used to configure user and system-wide settings. The system-wide profile is easy to access using the following:

PS>notepad $profile

Built-in Help Features

As mentioned earlier, cmdlets are the most basic component of PowerShell. Three of these cmdlets are essential in attempting to learn PowerShell. Even advanced users may still use these cmdlets on a daily basis:

• Get-Command— This cmdlet is essential in discovering what commands can be used and what might be available on the system to help with a certain task.

• Get-Help— When you are looking for additional details, specifically on other cmdlets, this is the main cmdlet to use.

• Get-Member— Absolute beginners don’t typically start using this cmdlet when first initiated into PowerShell, but for advanced users, and easier discovery, this cmdlet is very useful.

Let’s look at each of these cmdlets in more detail.

Get-Command

The Get-Command cmdlet can be used to get a listing of an entire list of cmdlets on the system, but it can also be used to get cmdlets that can be used for a specific task or purpose. For example, Get-Command alone in the console prints the entire list of available cmdlets available in the current console:

PS>Get-Command

If this is the first time you have ever opened a PowerShell console, how do you write to the console? How about displaying something as simple as “Welcome to SQL 2008”? You can pass something basic to Get-Command, such as the string "*write*":

PS>Get-Command *write*

What results is a listing of all the cmdlets that have the string "write" in any part of their name.

In addition, the preceding command also displays any applications and aliases found in the current user’s path.

PowerShell can be pretty smart. The preceding sample is actually a shortcut for something longer like this:

PS>Get-Command -Name *write*

Based on how the cmdlet is programmed, cmdlets can automatically assign a particular value to a parameter even when the parameter isn’t explicitly typed out.

Originally, we were looking for a cmdlet to display something on the console and found the cmdlet Write-Host. Let’s try it:

PS>Write-Host "Welcome to SQL 2008"

Get-Help

The learning curve with PowerShell can be relatively steep. Sometimes you can find a particular command for a particular task, such as the Write-Host cmdlet in the preceding section, but you might not always be sure how to actually use it. Write-Host is simple, but what if Write-Host had other useful features, or help was required for some other cmdlet?

Get-Help is a very useful cmdlet. Just using Get-Help alone provides some default help information:

PS>Get-Help

To get help on a particular cmdlet, you can use Get-Help and pass the other cmdlet as an argument:

PS>Get-Help Write-Host

That approach might not provide a lot of useful information; perhaps the –Full and –Examples parameters are more useful:

PS>Get-Help Write-Host -Full

Passing the –Full parameter gives a detailed description of the cmdlet and all its parameters (including what types of values they accept). If you are a more experienced user, the –Examples parameter is very useful, because it just gives some examples of using the cmdlet, which is an easy way to remember the syntax of a particular command:

PS>Get-Help Write-Host -Examples

Get-Member

Because everything in PowerShell is object based, some of the features that can be accessed are always visible. To find out more about a particular object, you can use the Get-Member cmdlet to look at all its members (the more interesting members of a .NET object are usually its properties and methods).

Using something simple like "AdventureWorks2008R2", you can easily look at PowerShell’s members (possibly without having to consult any .NET developer-focused documentation). "AdventureWorks2008R2" is a string—in other words, a combination of alphanumeric characters (that can include spaces). The following example is another way to display a string in the PowerShell console:

PS>"AdventureWorks2008R2"

PowerShell automatically recognizes this is a simple string and displays it.

A string can be easily displayed to the console, but what else can you do with a string object? In the .NET Framework, a string is really a System.String object. The .NET Framework provides a lot of functionality that can be used to deal with strings. Now let’s consider another example:

PS>" AdventureWorks2008R2"|Get-Member

From the preceding command, more information is displayed now, including TypeName:System.String, which confirms that this is a System.String object. One particular feature that Get-Member indicates is that there is a ToLower method supported by this particular object:

PS>"AdventureWorks2008R2".ToLower()

In this example, the ToLower method of the System.String object is used to change the string into all lowercase letters.